Los paquetes acumulativos están de moda

Los paquetes acumulativos están de moda en la comunidad de Ethereum y están destinados a ser la solución de escalabilidad clave para Ethereum en el futuro previsible.

Pero, ¿qué es exactamente esta tecnología, qué puede esperar de ella y cómo podrá usarla? Esta publicación intentará responder algunas de esas preguntas clave.

Antecedentes: ¿Qué es el escalado de capa 1 y capa 2?

Hay dos formas de escalar un ecosistema blockchain. Primero, puede hacer que la propia cadena de bloques tenga una mayor capacidad de transacción .

El principal desafío con esta técnica es que las cadenas de bloques con "bloques más grandes" son inherentemente más difíciles de verificar y es probable que se vuelvan más centralizadas.

Para evitar tales riesgos, los desarrolladores pueden aumentar la eficiencia del software del cliente o, de manera más sostenible, utilizar técnicas como la fragmentación para permitir que el trabajo de construcción y verificación de la cadena se divida en muchos nodos; el esfuerzo conocido como "eth2" actualmente está construyendo esta actualización a Ethereum.

En segundo lugar, puede cambiar la forma en que usa la cadena de bloques . En lugar de poner toda la actividad en la cadena de bloques directamente, los usuarios realizan la mayor parte de su actividad fuera de la cadena en un protocolo de "capa 2".

Hay un contrato inteligente en la cadena, que solo tiene dos tareas: procesar depósitos y retiros, y verificar las pruebas de que todo lo que sucede fuera de la cadena sigue las reglas.

Hay varias formas de hacer estas pruebas, pero todas comparten la propiedad de que verificar las pruebas en la cadena es mucho más económico que hacer el cálculo original fuera de la cadena.

Canales estatales vs Plasma vs Rollups

Los tres tipos principales de escalado de capa 2 son canales de estado , plasma y acumulaciones.

Son tres paradigmas diferentes, con diferentes fortalezas y debilidades, y en este punto estamos bastante seguros de que toda la escala de capa 2 cae aproximadamente en estas tres categorías (aunque existen controversias de nombres en los bordes, por ejemplo, ver "validium" ).

¿Cómo funcionan los canales?

Ver también: https://www.jeffcoleman.ca/state-channels y statechannels.org

Imagine que Alice le ofrece una conexión a Internet a Bob, a cambio de que Bob le pague $0,001 por megabyte. En lugar de realizar una transacción para cada pago, Alice y Bob utilizan el siguiente esquema de capa 2.

Primero, Bob pone $ 1 (o algún ETH o equivalente de moneda estable) en un contrato inteligente. Para realizar su primer pago a Alice, Bob firma un "boleto" (un mensaje fuera de la cadena), que simplemente dice "$0.001", y se lo envía a Alice.

Para hacer su segundo pago, Bob firmaría otro boleto que dice "$0.002" y se lo enviaría a Alice. Y así sucesivamente para tantos pagos como sea necesario. Cuando Alice y Bob terminen de realizar transacciones, Alice puede publicar el boleto de mayor valor para encadenarlo, envuelto en otra firma suya.

El contrato inteligente verifica las firmas de Alice y Bob, le paga a Alice el monto del boleto de Bob y le devuelve el resto a Bob.

Si Alice no está dispuesta a cerrar el canal (debido a malicia o falla técnica), Bob puede iniciar un período de retiro (por ejemplo, 7 días); si Alice no proporciona un boleto dentro de ese tiempo, entonces Bob recupera todo su dinero.

Esta técnica es poderosa: se puede ajustar para manejar pagos bidireccionales, relaciones de contratos inteligentes (por ejemplo, Alice y Bob hacen un contrato financiero dentro del canal) y composición (si Alice y Bob tienen un canal abierto y también Bob y Charlie, Alice puede interactuar sin confianza con Charlie).

Pero hay límites a lo que pueden hacer los canales.

Los canales no se pueden usar para enviar fondos fuera de la cadena a personas que aún no son participantes. Los canales no se pueden utilizar para representar objetos que no tengan un propietario lógico claro (p. ej., Uniswap).

Y los canales, especialmente si se utilizan para hacer cosas más complejas que simples pagos recurrentes, requieren una gran cantidad de capital para bloquearse.

¿Cómo funciona el plasma?

Ver también: el papel Plasma original y Plasma Cash .

Para depositar un activo, un usuario lo envía al contrato inteligente que administra la cadena Plasma. La cadena Plasma asigna a ese activo una nueva identificación única (por ejemplo, 537).

Cada cadena de Plasma tiene un operador (este podría ser un actor centralizado, o multisig, o algo más complejo como PoS o DPoS). Cada intervalo (esto podría ser de 15 segundos, una hora o cualquier intervalo), el operador genera un "lote" que consta de todas las transacciones de Plasma que han recibido fuera de la cadena.

Generan un árbol de Merkle, en el que en cada índice X del árbol hay una transacción que transfiere el ID de activo X si existe tal transacción y, de lo contrario, esa hoja es cero. Publican la raíz Merkle de este árbol a cadena.

También envían la rama Merkle de cada índice X al propietario actual de ese activo. Para retirar un activo, un usuario publica la sucursal de Merkle de la transacción más reciente que le envía el activo.

El contrato inicia un período de impugnación, durante el cual cualquiera puede intentar usar otras sucursales de Merkle para invalidar la salida al demostrar que (i) el remitente no era propietario del activo en el momento en que lo envió, o (ii) envió el activo a otra persona en algún momento posterior.

Si nadie prueba que la salida es fraudulenta durante (p. ej.) 7 días, el usuario puede retirar el activo.

Plasma proporciona propiedades más sólidas que los canales: puede enviar activos a participantes que nunca formaron parte del sistema y los requisitos de capital son mucho más bajos.

Pero tiene un costo: los canales no requieren datos en absoluto para conectarse en cadena durante el "funcionamiento normal", pero Plasma requiere que cada cadena publique un hash a intervalos regulares.

Además, las transferencias de Plasma no son instantáneas: hay que esperar a que finalice el intervalo y se publique el bloque.

Además, Plasma y los canales comparten una debilidad clave en común: la teoría del juego detrás de por qué son seguros se basa en la idea de que cada objeto controlado por ambos sistemas tiene algún "propietario" lógico.

Si a ese propietario no le importa su activo, puede resultar en un resultado "no válido" que involucre a ese activo. Esto está bien para muchas aplicaciones, pero es un factor decisivo para muchas otras (por ejemplo, Uniswap).

Incluso los sistemas en los que se puede cambiar el estado de un objeto sin el consentimiento del propietario (p. ej., sistemas basados en cuentas, en los que puede aumentar el saldo de alguien sin su consentimiento) no funcionan bien con Plasma.

Todo esto significa que se requiere una gran cantidad de "razonamiento específico de la aplicación" en cualquier despliegue realista de plasma o canales, y no es posible hacer un sistema de plasma o canal que solo simule el entorno completo de ethereum (o "el EVM") . Para solucionar este problema, llegamos a... resúmenes.

resúmenes

Consulte también: EthHub sobre resúmenes optimistas y resúmenes ZK .

El plasma y los canales son esquemas de capa 2 "completos", en el sentido de que intentan mover tanto los datos como la computación fuera de la cadena.

Sin embargo, los problemas fundamentales de la teoría de juegos en torno a la disponibilidad de datos significan que es imposible hacer esto de manera segura para todas las aplicaciones. El plasma y los canales evitan esto al basarse en una noción explícita de propietarios, pero esto les impide ser completamente generales.

Los paquetes acumulativos, por otro lado, son un esquema de capa 2 "híbrido".

Los rollups mueven el cómputo (y el almacenamiento de estado) fuera de la cadena, pero mantienen algunos datos por transacción en la cadena .

Para mejorar la eficiencia, utilizan una gran cantidad de trucos de compresión sofisticados para reemplazar los datos con computación siempre que sea posible.

El resultado es un sistema en el que la escalabilidad sigue estando limitada por el ancho de banda de datos de la cadena de bloques subyacente, pero en una proporción muy favorable: mientras que una transferencia de token ERC20 de capa base de Ethereum cuesta ~45 000 gas, una transferencia de token ERC20 en un paquete acumulativo ocupa 16 bytes de espacio en cadena y costos por debajo de 300 de gas.

El hecho de que los datos estén en la cadena es clave (nota: poner los datos "en IPFS" no funciona, porque IPFS no brinda consenso sobre si un dato determinado está disponible o no; los datos deben ir en una cadena de bloques).

Poner datos en la cadena y tener consenso sobre ese hecho permite que cualquier persona procese localmente todas las operaciones en el resumen si así lo desea, lo que les permite detectar fraudes, iniciar retiros o comenzar personalmente a producir lotes de transacciones.

La falta de problemas de disponibilidad de datos significa que un operador malicioso o fuera de línea puede causar incluso menos daño (p. ej., no puede causar un retraso de 1 semana), lo que abre un espacio de diseño mucho más grande para quién tiene derecho a publicar lotes y hace que los resúmenes sean mucho más fáciles. para razonar.

Y lo que es más importante, la falta de problemas de disponibilidad de datos significa que ya no es necesario asignar activos a los propietarios, lo que lleva a la razón clave por la cual la comunidad de Ethereum está mucho más entusiasmada con los paquetes acumulativos que con las formas anteriores de escalado de capa 2: los paquetes acumulativos son totalmente de propósito general, e incluso se puede ejecutar un EVM dentro de un paquete acumulativo, lo que permite que las aplicaciones Ethereum existentes migren a paquetes acumulativos casi sin necesidad de escribir ningún código nuevo .

OK, entonces, ¿cómo funciona exactamente un paquete acumulativo?

Hay un contrato inteligente en cadena que mantiene una raíz de estado : la raíz de Merkle del estado del resumen (es decir, los saldos de cuenta, el código del contrato, etc., que están "dentro" del resumen).

Cualquiera puede publicar un lote , una colección de transacciones en una forma altamente comprimida junto con la raíz del estado anterior y la raíz del nuevo estado (la raíz de Merkle después de procesar las transacciones).

El contrato verifica que la raíz de estado anterior en el lote coincida con su raíz de estado actual; si lo hace, cambia la raíz del estado a la nueva raíz del estado.

Para admitir depósitos y retiros, agregamos la capacidad de tener transacciones cuya entrada o salida está "fuera" del estado de resumen.

Si un lote tiene entradas desde el exterior, la transacción que envía el lote también debe transferir estos activos al contrato de resumen. Si un lote tiene salidas al exterior, luego de procesar el lote, el contrato inteligente inicia esos retiros.

¡Y eso es! Excepto por un detalle importante: ¿cómo saber que las raíces posteriores al estado en los lotes son correctas?

Si alguien puede enviar un lote con cualquier raíz posterior al estado sin consecuencias, podría simplemente transferirse todas las monedas dentro del resumen.

Esta pregunta es clave porque hay dos familias de soluciones muy diferentes para el problema, y estas dos familias de soluciones conducen a los dos tipos de acumulaciones.

Rollups optimistas vs ZK rollups

Los dos tipos de rollups son:

1. Rollups optimistas , que utilizan pruebas de fraude : el contrato de rollup realiza un seguimiento de todo su historial de raíces estatales y el hash de cada lote.

   
   

   Si alguien descubre que un lote tenía una raíz posterior al estado incorrecta, puede publicar una prueba en cadena, demostrando que el lote se calculó incorrectamente.

   
   

   El contrato verifica la prueba y revierte ese lote y todos los lotes posteriores.

   
   

2. Rollups ZK , que usan pruebas de validez : cada lote incluye una prueba criptográfica llamada ZK-SNARK (por ejemplo, usando el protocolo PLONK ), que prueba que la raíz posterior al estado es el resultado correcto de ejecutar el lote.

   
   

   No importa cuán grande sea el cálculo, la prueba se puede verificar muy rápidamente en la cadena.

Existen compensaciones complejas entre los dos tipos de acumulaciones:

En general, mi opinión es que, a corto plazo, es probable que las acumulaciones optimistas ganen para el cálculo de EVM de propósito general y que las acumulaciones ZK probablemente ganen para pagos simples, intercambio y otros casos de uso específicos de la aplicación, pero en el Los rollups de ZK a mediano y largo plazo ganarán en todos los casos de uso a medida que mejore la tecnología ZK-SNARK.

Anatomía de una prueba de fraude

La seguridad de un paquete acumulativo optimista depende de la idea de que si alguien publica un lote no válido en el paquete acumulativo, cualquier otra persona que estuviera al tanto de la cadena y haya detectado el fraude puede publicar una prueba de fraude, demostrando al contrato que ese lote no es válido y debe revertirse.

Una prueba de fraude que afirme que un lote no es válido contendría los datos en verde: el lote en sí (que podría verificarse con un hash almacenado en cadena) y las partes del árbol Merkle necesarias para probar solo las cuentas específicas que se leyeron y/ o modificado por el lote.

Los nodos del árbol en amarillo se pueden reconstruir a partir de los nodos en verde, por lo que no es necesario proporcionarlos.

Estos datos son suficientes para ejecutar el lote y calcular la raíz posterior al estado (tenga en cuenta que esto es exactamente igual a cómo los clientes sin estado verifican bloques individuales).

Si la raíz posterior al estado calculada y la raíz posterior al estado proporcionada en el lote no son iguales, entonces el lote es fraudulento.

Se garantiza que si un lote se construyó incorrectamente y todos los lotes anteriores se construyeron correctamente , entonces es posible crear una prueba de fraude que muestre que el lote se construyó incorrectamente.

Tenga en cuenta la afirmación sobre los lotes anteriores: si hubo más de un lote no válido publicado en el resumen, entonces es mejor intentar probar que el primero no es válido. Por supuesto, también se garantiza que si un lote se construyó correctamente, nunca será posible crear una prueba de fraude que demuestre que el lote no es válido.

¿Cómo funciona la compresión?

Una transacción simple de Ethereum (para enviar ETH) requiere ~110 bytes. Sin embargo, una transferencia ETH en un resumen solo requiere ~12 bytes:

Parte de esto es simplemente una codificación superior: el RLP de Ethereum desperdicia 1 byte por valor en la longitud de cada valor. Pero también hay algunos trucos de compresión muy inteligentes que están sucediendo:

• Nonce : el propósito de este parámetro es evitar repeticiones. Si el nonce actual de una cuenta es 5, la próxima transacción de esa cuenta debe tener un nonce 5, pero una vez que se procese la transacción, el nonce en la cuenta se incrementará a 6 para que la transacción no se pueda procesar nuevamente.

  
  

  En el resumen, podemos omitir el nonce por completo, porque solo recuperamos el nonce del estado anterior; si alguien intenta reproducir una transacción con un nonce anterior, la firma no se verificará, ya que la firma se verificará con los datos que contienen el nuevo nonce superior.

  
  

• Precio del gas : podemos permitir que los usuarios paguen con un rango fijo de precios del gas, p. una elección de 16 potencias consecutivas de dos.

  
  

  Alternativamente, podríamos simplemente tener un nivel de tarifa fijo en cada lote, o incluso mover el pago de gasolina fuera del protocolo de acumulación por completo y hacer que los transactores paguen a los creadores de lotes para su inclusión a través de un canal.

  
  

• Gas : de manera similar podríamos restringir el gas total a una elección de potencias consecutivas de dos. Alternativamente, podríamos tener un límite de gas solo a nivel de lote.

  
  

• Para : podemos reemplazar la dirección de 20 bytes con un índice (por ejemplo, si una dirección es la 4527 agregada al árbol, solo usamos el índice 4527 para referirnos a ella).

  
  

  Agregaríamos un subárbol al estado para almacenar el mapeo de índices a direcciones).

  
  

• Valor : podemos almacenar valor en notación científica. En la mayoría de los casos, las transferencias solo necesitan de 1 a 3 dígitos significativos.

  
  

• Firma : podemos usar firmas agregadas BLS , lo que permite agregar muchas firmas en una sola firma de ~ 32-96 bytes (según el protocolo).

  
  

  Luego, esta firma se puede verificar con el conjunto completo de mensajes y remitentes en un lote, todo a la vez.

  
  

  El ~0.5 en la tabla representa el hecho de que existe un límite en la cantidad de firmas que se pueden combinar en un agregado que se puede verificar en un solo bloque, por lo que los lotes grandes necesitarían una firma por cada ~100 transacciones.

Un truco de compresión importante que es específico de los paquetes acumulativos ZK es que si una parte de una transacción solo se usa para la verificación y no es relevante para calcular la actualización del estado, entonces esa parte se puede dejar fuera de la cadena.

Esto no se puede hacer en un resumen optimista porque esos datos aún deberían incluirse en la cadena en caso de que deban verificarse más tarde en una prueba de fraude, mientras que en un resumen ZK, el SNARK que prueba la corrección del lote ya prueba que cualquier dato necesario para la verificación.

Un ejemplo importante de esto son los resúmenes que preservan la privacidad: en un resúmen optimista, el ZK-SNARK de ~500 bytes utilizado para la privacidad en cada transacción debe ir en cadena, mientras que en un resúmen ZK, el ZK-SNARK que cubre todo el lote ya no deja Dudo que los ZK-SNARK "internos" sean válidos.

Estos trucos de compresión son clave para la escalabilidad de los paquetes acumulativos; sin ellos, los resúmenes serían quizás solo una mejora de ~10 veces en la escalabilidad de la cadena base (aunque hay algunas aplicaciones específicas de computación pesada donde incluso los resúmenes simples son poderosos), mientras que con los trucos de compresión, el factor de escala puede superar las 100 veces durante casi todas las aplicaciones.

¿Quién puede enviar un lote?

Hay varias escuelas de pensamiento sobre quién puede enviar un lote en un resumen optimista o ZK.

En general, todos están de acuerdo en que para poder enviar un lote, un usuario debe hacer un depósito grande; si ese usuario alguna vez envía un lote fraudulento (por ejemplo, con una raíz de estado no válida), ese depósito se quemará en parte y se entregará en parte como recompensa al probador de fraude. Pero más allá de eso, hay muchas posibilidades:

• Anarquía total : cualquiera puede enviar un lote en cualquier momento. Este es el enfoque más simple, pero tiene algunos inconvenientes importantes.

  
  

  En particular, existe el riesgo de que varios participantes generen e intenten enviar lotes en paralelo, y solo uno de esos lotes se puede incluir con éxito.

  
  

  Esto conduce a una gran cantidad de esfuerzo desperdiciado en la generación de pruebas y/o gas desperdiciado en la publicación de lotes en cadena.

  
  

• Secuenciador centralizado : hay un solo actor, el secuenciador , que puede enviar lotes (a excepción de los retiros: la técnica habitual es que un usuario primero puede enviar una solicitud de retiro, y luego, si el secuenciador no procesa ese retiro en el siguiente lote, entonces el usuario puede enviar un lote de una sola operación por sí mismo).

  
  

  Este es el más "eficiente", pero depende de un actor central para la vitalidad.

  
  

• Subasta de secuenciadores : se realiza una subasta (por ejemplo, todos los días) para determinar quién tiene derecho a ser el secuenciador del día siguiente.

  
  

  Esta técnica tiene la ventaja de que recauda fondos que podrían ser distribuidos por ej. un DAO controlado por el rollup (ver: Subastas MEV )

  
  

• Selección aleatoria del conjunto de PoS : cualquiera puede depositar ETH (o quizás el token de protocolo propio del paquete acumulativo) en el contrato del paquete acumulativo, y el secuenciador de cada lote se selecciona aleatoriamente de uno de los depositantes, con la probabilidad de ser seleccionado proporcional a la cantidad depositado.

  
  

  El principal inconveniente de esta técnica es que conduce al bloqueo de grandes cantidades de capital innecesarias.

  
  

• Votación DPoS : hay un solo secuenciador seleccionado con una subasta, pero si se desempeñan mal, los poseedores de tokens pueden votar para expulsarlos y realizar una nueva subasta para reemplazarlos.

Disposición de división por lotes y estado raíz

Algunos de los paquetes acumulativos que se están desarrollando actualmente utilizan un paradigma de "lote dividido", donde la acción de enviar un lote de transacciones de capa 2 y la acción de enviar una raíz de estado se realizan por separado.

Esto tiene algunas ventajas clave:

1. Puede permitir que muchos secuenciadores publiquen lotes en paralelo para mejorar la resistencia a la censura, sin preocuparse de que algunos lotes no sean válidos porque otro lote se incluyó primero.

   
   

2. Si una raíz de estado es fraudulenta, no necesita revertir todo el lote; puede revertir solo la raíz del estado y esperar a que alguien proporcione una nueva raíz del estado para el mismo lote.

   
   

   Esto brinda a los remitentes de transacciones una mejor garantía de que sus transacciones no se revertirán.

Entonces, en general, hay un zoológico bastante complejo de técnicas que intentan equilibrar complicadas compensaciones que involucran eficiencia, simplicidad, resistencia a la censura y otros objetivos.

Todavía es demasiado pronto para decir qué combinación de estas ideas funciona mejor; el tiempo dirá.

¿Cuánta escalabilidad te dan los rollups?

En la cadena Ethereum existente, el límite de gas es de 12,5 millones, y cada byte de datos en una transacción cuesta 16 de gas.

Esto significa que si un bloque no contiene nada más que un solo lote (diremos que se usa un resumen ZK, gastando 500k de gas en la verificación de prueba), ese lote puede tener (12 millones/16) = 750,000 bytes de datos.

Como se muestra arriba, un resumen para transferencias ETH requiere solo 12 bytes por operación de usuario, lo que significa que el lote puede contener hasta 62 500 transacciones.

Con un tiempo de bloque promedio de 13 segundos , esto se traduce en ~4807 TPS (en comparación con 12,5 millones/21000/13 ~= 45 TPS para transferencias ETH directamente en Ethereum).

Aquí hay una tabla para algunos otros casos de uso de ejemplo:

La ganancia de escalabilidad máxima se calcula como (costo de gas L1) / (bytes en resumen * 16) * 12 millones / 12,5 millones.

Ahora, vale la pena tener en cuenta que estas cifras son demasiado optimistas por varias razones. Lo que es más importante, un bloque casi nunca contendría solo un lote, al menos porque hay y habrá múltiples acumulaciones.

Segundo, los depósitos y retiros seguirán existiendo. En tercer lugar, a corto plazo, el uso será bajo y, por tanto, dominarán los costes fijos. Pero incluso teniendo en cuenta estos factores, se espera que las ganancias de escalabilidad de más de 100 veces sean la norma.

Ahora, ¿qué sucede si queremos superar ~1000-4000 TPS (según el caso de uso específico)? Aquí es donde entra en juego la fragmentación de datos eth2 .

La propuesta de fragmentación abre un espacio de 16 MB cada 12 segundos que se puede llenar con cualquier dato, y el sistema garantiza el consenso sobre la disponibilidad de esos datos. Este espacio de datos puede ser utilizado por acumulaciones.

Estos ~1398k bytes por segundo son una mejora de 23 veces sobre los ~60 kB/seg de la cadena Ethereum existente y, a largo plazo, se espera que la capacidad de datos crezca aún más.

Por lo tanto, los paquetes acumulativos que utilizan datos fragmentados de eth2 pueden procesar colectivamente hasta ~100 000 TPS, e incluso más en el futuro.

¿Cuáles son algunos desafíos que aún no se han resuelto por completo en los resúmenes?

Si bien el concepto básico de un paquete acumulativo ahora se comprende bien, estamos bastante seguros de que son fundamentalmente factibles y seguros, y ya se han implementado varios paquetes acumulativos en la red principal, todavía hay muchas áreas de diseño de paquetes acumulativos que no se han explorado bien, y bastantes desafíos para llevar por completo grandes partes del ecosistema Ethereum a acumulaciones para aprovechar su escalabilidad.

Algunos desafíos clave incluyen:

• Incorporación de usuarios y ecosistemas : no muchas aplicaciones usan resúmenes, los resúmenes no son familiares para los usuarios y pocas billeteras han comenzado a integrar resúmenes.

  
  

  Los comerciantes y las organizaciones benéficas aún no los aceptan para pagos.

  
  

• Transacciones de resumen cruzado : movimiento eficiente de activos y datos (p. ej., resultados de Oracle) de un resumen a otro sin incurrir en el gasto de pasar por la capa base.

  
  

• Incentivos de auditoría : ¿cómo maximizar la posibilidad de que al menos un nodo honesto realmente verifique completamente un resumen optimista para que puedan publicar una prueba de fraude si algo sale mal?

  
  

  Para acumulaciones a pequeña escala (hasta unos pocos cientos de TPS), este no es un problema importante y uno simplemente puede confiar en el altruismo, pero para acumulaciones a mayor escala se necesita un razonamiento más explícito sobre esto.

  
  

• Explorando el espacio de diseño entre el plasma y los resúmenes : ¿existen técnicas que ponen en cadena algunos datos relevantes para la actualización del estado, pero no todos , y hay algo útil que pueda resultar de eso?

  
  

• Maximización de la seguridad de las confirmaciones previas : muchos paquetes acumulativos brindan una noción de "confirmación previa" para una UX más rápida, donde el secuenciador promete de inmediato que una transacción se incluirá en el siguiente lote, y el depósito del secuenciador se destruye si rompen su palabra.

  
  

  Pero la seguridad económica de este esquema es limitada, debido a la posibilidad de hacer muchas promesas a muchos actores al mismo tiempo. ¿Se puede mejorar este mecanismo?

  
  

• Mejorar la velocidad de respuesta a los secuenciadores ausentes : si el secuenciador de un paquete acumulativo se desconecta repentinamente, sería valioso recuperarse de esa situación de la manera más rápida y económica, ya sea saliendo en masa rápida y económicamente a un paquete acumulativo diferente o reemplazando el secuenciador.

  
  

• ZK-VM eficiente : genera una prueba ZK-SNARK de que el código EVM de propósito general (o alguna VM diferente en la que se pueden compilar los contratos inteligentes existentes) se ha ejecutado correctamente y tiene un resultado determinado.

Conclusiones

Los rollups son un nuevo y poderoso paradigma de escalamiento de capa 2, y se espera que sean la piedra angular del escalamiento de Ethereum en el futuro a corto y mediano plazo (y posiblemente también a largo plazo).

Han visto una gran cantidad de entusiasmo por parte de la comunidad Ethereum porque, a diferencia de los intentos anteriores de escalado de capa 2, pueden admitir código EVM de propósito general, lo que permite que las aplicaciones existentes se migren fácilmente.

Lo hacen al hacer un compromiso clave: no intentar salir completamente de la cadena, sino dejar una pequeña cantidad de datos por transacción en la cadena.

Hay muchos tipos de resúmenes y muchas opciones en el espacio de diseño: uno puede tener un resumen optimista usando pruebas de fraude o un resumen ZK usando pruebas de validez (también conocido como ZK-SNARK).

El secuenciador (el usuario que puede publicar lotes de transacciones para encadenar) puede ser un actor centralizado, un free-for-all o muchas otras opciones intermedias.

Los paquetes acumulativos aún son una tecnología en etapa inicial y el desarrollo continúa rápidamente, pero funcionan y algunos (en particular, Loopring , ZKSync y DeversiFi ) ya se han estado ejecutando durante meses. Espere un trabajo mucho más emocionante que surja del espacio acumulativo en los años venideros.